In 69893f5 I've started to explore implementing this in the editor and quickly ran into an issue with specificity — currently the .wp-block-buttons.is-layout-flex wins over .wp-container-1, so that the block-level in theme.json styles take precedence. However, we want the real value at the individual block level to win out.

If we then up the specificity of the block level so that it also includes the block className (e.g. .wp-block-buttons.wp-container-1), that superficially fixes things when there's a style set for the individual block. However, if we remove that value, then the fallback styles for gap win out.

So, I think this means that for this implementation to work, we might need to explore one of the following options:

1. The higher specificity of the individual block only occurs if it really has a value (e.g. we could force !important to be added — however this could be a deal breaker given that folks are wanting to remove usage of !important elsewhere).
2. Or, perhaps we look at replacing how the CSS variable approach works for the fallback root level value. Maybe the block-level class based approach we're going with is enough so that we can have that fallback generated elsewhere (e.g. in theme.json via the presets-like approach).

So, this solution / approach might need to incorporate the some of the ideas from the presets approach in #39708 in order to be viable (it might be a neater approach overall if we can consolidate a bit).

I'll continue hacking away at this over the coming days.

Size Change: +883 B (0%)

Total Size: 1.25 MB

_{compressed-size-action}

I've taken a tiny step forward in b2bc04a to experiment with getting the classname for the block and combining that with the container-id classname to increase specificity. If we also remove the fallback styles, then this (at least superficially) seems to solve the specificity issue (on the frontend, at least): 😀

Next up, to see if this is viable, some more to-dos (I'm jotting them down here so that I remember!):

• In the theme JSON output, we need to now generate the fallback styles (preferably without relying on a CSS variable) — perhaps this could be a rule like body .is-layout-flex so that its specificity is the lowest of the three ways we generate styles.
• Try replicating these rules in the editor, too
• See if we need to factor in blocks that don't use a classname (or opt-out of generating custom gap styles for blocks that don't support a classname, as I think we do need a classname for this approach to work)

I like this idea @andrewserong Thanks for working on it.

Just for the record, I tried experimenting with splitting the CSS vars, one for root and another for layout over in #41040

But I think I like the classname/CSS approach better, especially if we can tie it into any meaningful semantic classnames work we do.

Just for the record, I tried experimenting with splitting the CSS vars

Oh, nice, thanks for digging in! I think the more we experiment the better, that we way can compare concrete examples 😀

In the theme JSON output, we need to now generate the fallback styles (preferably without relying on a CSS variable) — perhaps this could be a rule like body .is-layout-flex so that its specificity is the lowest of the three ways we generate styles.

I think I've figured out how to get this working, hacked in 896c46e, which appears to mean we now have styles rendered out with the correct specificity so that it goes (from highest specificity to least):

1. Individual block level attributes
2. Block level blockGap in theme.json
3. Fallback gap value set in global styles, attached to body and descendant .is-layout-{type} selector

Now that that's hacked in there and seems to be working, next week I'll:

• Give this a rebase and move the code to the appropriate files in the 6.1 directory
• Tidy up to remove some of the hacks
• Try implementing in the editor

Still very much a hack, but in 4492cd7, I've now got the approach working in the site editor, so adjusting spacing at the block level in global styles now appears to be working. Here's a not exciting screenshot of the styles output:

Here's a slightly more exciting screengrab of adjusting block spacing in global styles for the social icons block:

Next up: work out a better place to put everything, and perhaps see if we can consolidate with ideas from #39708.

This is coming along really well so far. Thanks for running with it. I'm feeling positive about the direction, especially if we look into the use of CSS vars and/or classnames to drive the layout styles. Referring to your previous work in #38974

Would this PR also resolve #40516?

Would this PR also resolve #40516?

Oh, thanks for linking that one @ramonjd! I think so — so far with this exploration, it looks like it should be possible for us to handle all the blockGap settings without using the CSS variable at all, if I'm not mistaken. I've done that in the server-side implementation, but still need to update the in editor styling to see if it's viable, but I've been a bit distracted by trying to land some bug fixes elsewhere this week 🙂

I've given this a rebase and reworked part of the PHP implementation slightly to move the layout gap styles generation to its own function. This way it plays nicely with the changes from: #41160 so that the gap styles per block are output in the individual style tags for each of those blocks.

In the process, I've removed the CSS variable generation in PHP. For backwards compatibility, we'll probably want to add it back in again as a preset, outside of the PROPERTIES_METADATA process. So, some tasks for next week:

• Add comparable layout gap style generation logic to the editor
• Add back in CSS variable generation potentially, via a preset
• A bit more consolidation so that it can neatened up for review

There's still lots more that needs to be tidied up, but in dca159d I now have the gap value in global styles in the site editor being generated from the definitions in theme.json.

Top-of-mind things to implement next:

• Remove duplication / erroneous addition of layout classes in the editor where there should be any (e.g. on the Button and Social Icon (singular) blocks)
• Restore outputting the base CSS variable for backwards compatibility (and support for the ad hoc implementation of the Gallery block)
• See how we can include fallback gap styles that are aware of the particular block being rendered — essentially, ensure that we don't break Layout: Add default fallback gap value in block.json, and set to 2em for Columns blocks #41098
• When rendering out the block-level layout styles, can we do a look up if the block name is provided, so that we only output the relevant styles? (It's probably not a huge issue right now, but currently styles for each of the layout types are output)
• Fix rendering of root flow gap styles in the post editor

@juanmaguitar can we check what new classes are being outputted to communicate to developers? There's also #41993. Would be good to have a clear list of what is new in 6.1.

@mtias, @justintadlock is already working on bringing visibility to this

There is no default 'display:flex' in the 6.1 beta 1 WordPress version for a buttons block. As a result - flex justify classes don't work.
Maybe this is the case for another flex blocks as well.

In the WordPress 6.0:
https://i.imgur.com/vCsbLLq.png

In the 6.1 beta 1:
https://i.imgur.com/UP2JVS0.png

Is this a bug or a new feature?
Thank you!

@exstheme thanks for reporting the issue you've run into. display:flex rules continue to be output in 6.1, however instead of being attached to the wp-container-$id based rule, they are attached to the is-layout-flex classname. In my local environment, testing with blocks-based and classic themes, these rules appear to still be output in 6.1. E.g. here's the rule in TwentyTwentyOne theme:

Is your theme dequeueing the global styles inline CSS 'global-styles-inline-css'? Since this PR is now closed, it might be worth opening a new issue if you believe you've found a bug that needs investigating.

Hello, dear @andrewserong !

Thank you very much for your answer and your time!

And thank you for your pointing me to 'global-styles-inline-css' styles.
In deed, I have dequeued this styles:

wp_dequeue_style('global-styles');

because we're not using them in our theme. I have found that 14kB of inline styles that are printed in the head and cannot be cached as a normal CSS file is a little bit overkilling.

Maybe it would be better to add this super important styles to the wp-includes/css/dist/block-library/style.min.css:
https://i.imgur.com/C4zIkQb.png
instead of printing them inline?

body .is-layout-flex{
    display: flex;
}
body .is-layout-flex{
    flex-wrap: wrap;
    align-items: center;
}

And why they are printed separately? The selector is the same.

For now I will add these CSS rules to my theme's CSS file to be compatible with WP 6.1.

Once again thank you for your attention!

Best regards!

A byproduct of the layout refactor is that blockGap can now be set at the block level in theme.json and via the global styles UI, as gap styles are now also output via the above layout type classnames, using direct CSS values, instead of the blockGap CSS variable --wp--style--block-gap.

I noticed this breaking change if the theme tries to override the CSS variable on the block level. I'm experimenting with re-building my site with Beaumont and this CSS rule no longer works - https://themes.trac.wordpress.org/browser/beaumont/0.1.5/style.css#L352.

I just wanted to mention this issue. But I think my example here can be solved by adding blockGap support to the Post Template block.

Thanks for the update @exstheme, glad you could find a workaround. If you're looking into adopting theme.json at any point in the future, you might be able to reduce the output by removing color presets, etc, so that you can then take advantage of the generated layout styles.

And why they are printed separately? The selector is the same.

Most of the styles are grouped together, but the display rule has special handling because it isn't handled by the usual safe CSS filter, so it's currently output separately. I believe the plan is to consolidate / group together rules in global styles for 6.2 — the consolidation in this PR was at the block level. Although there is an addition of a small amount of duplication in this particular rule, on balance, we still have a reduction in the Layout CSS output for 6.1

I noticed this breaking change if the theme tries to override the CSS variable on the block level. I'm experimenting with re-building my site with Beaumont and this CSS rule no longer works - https://themes.trac.wordpress.org/browser/beaumont/0.1.5/style.css#L352.

Thanks for the heads-up @Mamaduka! I believe block-level gap control wasn't previously available in global styles, so yes, it does sound like for some themes there'll be a breaking change if folks have been overriding the CSS variable like that. The Post Template block is a bit of a weird case because it currently partially opts-in to the layout support, and it also has its own existing gap rule for the grid layout in its style.scss file — I think that might have been partly the reason why it hasn't formally opted-in for block spacing controls (along with the unusual relationship between Query Loop and Post Template blocks).

Do you know what the desired result is from that existing rule? (If we have a concrete use case, we can add a suggested fix for themes like this in the dev note if it's a common thing in themes — they might be able to target the desired CSS properties now instead of relying on the CSS variable?). It might also be worth opening up a separate issue for the problem of overriding post template spacing so we can investigate further, if it isn't already covered in the request in #39380

Sounds good. I'll have a look at #39380.

Do you know what the desired result is from that existing rule?

I think mentioning a simple upgrade path for similar cases in the DevNote would be great.

Cc. @andersnoren, any thoughts on desired results here?

@Mamaduka Beaumont has separators between each item in the Query Loop, and the --wp--style--block-gap is set to 0 so the spacing between the separators could be handled entirely in the Site Editor prior to 6.1. It's the only one of my block themes that does this, and I haven't seen any others do it either, so it might be an edge case.

This is how it looks with the CSS variable set to 0 in style.css (running 6.0 without Gutenberg):

And without the CSS variable set to 0 (also how it looks running Gutenberg right now):

Awesome, thank you for confirming George and Anders, I'll download Beaumont and have a play to see what the best fix might be.

It looks like you just recently added a styling rule to account for this one @andersnoren, but from testing locally, I think you might also be able to add the following to styles.blocks in your theme.json file to set that particular gap to 0 (no need to, though, the rule you've added looks good to me):

			"core/post-template": {
				"spacing": {
					"blockGap": "0"
				}
			},

Here's how adding that looks in my local environment:

I'd be slightly hesitant about suggesting that as a general fix, though, because the Post Template block doesn't properly support switching between flow and flex layouts — switching to grid adds the block's ad hoc is-flex-container classname rather than using the is-layout-flex logic from the layout support, so blockGap output doesn't work correctly there (it still outputs the * + * rule instead of a gap rule). Refactoring that logic is a blocker for opting in that block to blockGap more explicitly. I'll open a separate issue for that if one doesn't already exist, because it'd be great to improve layout support for Query Loop / Post Template for 6.2.

It's the only one of my block themes that does this, and I haven't seen any others do it either, so it might be an edge case.

Good to know. If we encounter any other cases of this, I'm happy to write something up for the dev notes. If not, it might be better to leave it off since it appears to be quite a specific case particular to that block.

As an aside, that's a very nice looking theme!

@andrewserong Oh, I managed to completely miss that – I must have had the Gutenberg plugin inactive when I tested it. I'm always happy to remove a little bit of CSS, so thanks for the tip (and the kind words)!